1. Field of the Invention
The present invention relates to computer implemented transaction processing systems including stand-alone and distributed transaction processing systems. More particularly, the present invention relates to the use of computer implemented objects to implement a transaction processing system that supports object oriented transaction processing, but also integrates with the Transarc Encina procedural transaction management service. Still more particularly, the present invention provides a system and method for causing object oriented transaction processing applications to interoperate with procedural transaction processing applications developed for the Encina product. Interoperation requires that object generated requests and Encina transactional requests can be used within a single atomic transaction without requiring use of a transaction gateway.
2. Background and Related Art
Computer implemented transaction processing systems are used for critical business tasks in a number of industries. A transaction defines a single unit of work that must either be fully completed or fully purged without action. For example, in a bank automated teller machine (ATM) from which a customer seeks to withdraw money, the actions of issuing the money, reducing the balance of money on hand in the machine and reducing the customer's bank balance must all occur or none of them must occur. Failure of one of the subordinate actions would lead to inconsistency between the records and actual occurrences.
Distributed transaction processing involves a transaction that affects resources at more than one physical or logical location. In the above example, an ATM transaction affects resources managed at the local ATM device as well as bank balances managed by a bank's main computer. A distributed transaction may not be physically distributed bit may involve cooperating tasks that must be completed in synchrony for successful transaction completion.
The X/Open Company Limited (X/Open is a trademark of X/Open Company Ltd.) has promulgated a guide that describes one model for implementing distributed transaction processing. The X/Open Guide, Distributed Transaction Processing Reference Model, October, 1991, discusses the components of a distributed transaction system and the interrelationships between them. The X/Open Distributed Transaction Processing Model (the DTP Model) describes three main components: an Application Program (AP), a Transaction Manager (TM), and one or more Resource Managers (RMs). The Application Program uses and modifies the resources controlled by one or more of the Resource Managers. The Transaction Manager is responsible for global transactions and coordinates the decision whether to commit or roll-back the actions taken by the Resource Managers. (Commit causes the resources to be updated while roll-back causes all work to be discarded returning the resources to the state they were in upon transaction initiation.) The Resource Managers manage specific resources. Resource managers may include a database management system (DBMS), a file system, or similar resource.
Object oriented programming systems are designed to increase the efficiency of program development by enabling object reuse and simplifying system maintenance through clear separation of function.
Each object in an object oriented system encapsulates the data for that object and the procedures or methods for operating on that data. Encapsulation means that the data for an object can be manipulated only by that object using the defined methods.
Object oriented systems also implement object inheritance. Inheritance allows a more specific object to be derived from a general object. The more specific object can "inherit" all of the data and methods of the parent object, but can override selected data and methods and add others to implement its unique function.
The application of object oriented techniques to transaction processing systems raises many new issues but offers opportunities to increase system efficiency through the use of object oriented principles. The Object Management Group, Inc. (OMG) has established standards for interoperable object oriented systems. The overall architecture defined by OMG is the Common Object Request Broker Architecture (CORBA). CORBA defines the interactions between objects, and in particular, between distributed objects in different computer systems. OMG has accepted a specification to standardize transaction processing in object oriented systems. This specification, entitled the Object Transaction Service (OTS) Specification, sets forth the requirements for object services necessary to implement a transaction processing system. The OTS specification uses many of the unique capabilities of object oriented systems. The OTS model, however, is designed to allow object oriented systems to operate with the X/Open DTP model and with existing procedural transaction processing systems. The OTS Specification does not, however, define a system for allowing interoperability in a system supporting both object oriented and procedural requests in a single atomic transaction.
The OMG Object Transaction Service describes mapping of the object oriented interfaces to existing X/Open DTP interfaces to show correspondence between elements of the interfaces. This mapping is all that is specified in the OMG submission. The overall problem remains to find a mechanism to isolate the application program interfaces and then to develop specific methods (procedures) to implement that isolation. The first problem within this overall problem is to define the methods necessary to allow object oriented transactional requests to interoperate with procedural transactional requests. Specifically, the first problem is to interoperate with procedural transactional requests from the Transarc Encina product. These methods must allow for and support coordination of two-phase commit protocols between the OMG Object Transaction Service model and the Encina product. The OTS Specification mapping is between OMG functions (such as demarcation, propagation, involvement, and coordination) and Encina transaction manager interfaces (such as the formal two-phase commit protocols, transaction identifiers, and transaction states). The two phase commit coordination must occur within the transaction service and be isolated from the user interface level.
A second problem is the lack of a mechanism to allow transactional object oriented application program requests to effectively exist with Encina transactional procedural application program requests in a single atomic transaction. In particular, there is a need to develop an object based system and method to operate object-oriented application interfaces while also operating Encina transaction services without requiring changing the Encina procedural operations within an application program.
An additional problem is the need for an object based structure that is flexible enough to allow the Encina procedural transaction manager to be used by the object oriented system without changing that object structure. Creating such an object structure would allow OMG Object Transaction Service interfaces to the client applications, Object Request Brokers, and resources (Resource Managers) to be preserved and while also preserving the classes that implement the function defined in the OMG OTS class specifications.
A related technical problem is the need to develop a set of object oriented classes to efficiently connect object oriented applications to procedural transaction managers without modifying either the procedural transaction manager or existing procedural applications. A solution to this problem is defined by U.S. patent application Ser. No. 08/320,357 entitled, "A System and Method for Creating an Object Oriented Transaction Service that Interoperates with Procedural Transaction Coordinators," which was filed on Oct. 11, 1994.
The technical problem addressed by the present invention is to develop a set of object oriented classes and class structure that will allow transactional requests to exist in a single atomic transaction with existing Encina transactional requests. This interoperation must be done without requiring the modification of either the Encina transaction manager or the existing applications using Encina interfaces. This interoperation must be done without requiring a gateway function between the transaction services.